Testing of software often is performed concurrently with development of the software in an effort to improve quality of the software relatively early in the lifecycle of the software. However, defects in the software commonly are discovered in a development cycle that occurs after the development cycle in which the defect is introduced into the software. Identifying and analyzing the defect in such circumstance may be relatively challenging.
As the development of the software progresses from one cycle to another, tracing a defect to a particular development cycle may enable an evaluation and understanding of the quality of a feature in the software that is developed in a particular cycle. An inability to do so may introduce any of a variety of issues. For example, risk evaluation and course correction may become relatively difficult when the exact software code change that caused the defect is not known. It may become relatively difficult to divert resources for addressing the defect to the correct components of the software and/or the appropriate engineering teams. Feedback on the effectiveness of processes adopted for engineering teams may become relatively limited. Feedback on individuals and their teams based on certain patterns of defects may become relatively limited. Ongoing improvement in quality of the software may become less predictable as the Root Cause Analysis effort on existing defects becomes less effective if the exact code change that introduced the defect is not known.
Attempts have been made to manually address such issues. For instance, tracking tools, such as Visual Studio® Team Server (VSTS) or Product Studio™, rely on the effectiveness of a defect finder to link a defect to a software feature or software development cycle. The person filing the defect usually associates additional information with the defect, linking the defect to a previously released feature and/or a previous development cycle. Using this information, selective defects typically are analyzed in a triage or a separate exercise to create a manual report of defects that are linked to past development cycles. However, the person filing the defect likely is not the person who tested the software feature during the development cycle of the software. If the person filing the defect does not have the aforementioned information, that person may not be able to accurately link the defect to a product feature. Moreover, such manual techniques traditionally are not scalable, which may render such techniques relatively ineffective.